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Abstract 


This  project  investigated  the  feasibility  and  level  of  effort  in  acquiring  the  data  required  by  the 
Information  Integration  Display  (IID)  system  from  current  and  near-future  submarine  systems. 
An  IID  Information  Matrix  is  presented  that  describes  183  unique  information  types  needed  by 
the  IID.  For  each  of  these,  we  identify  potential  submarine  system  source(s),  recommend 
method(s)  to  make  this  information  available  to  the  IID,  and  list  properties,  both  as  needed  by  the 
IID  and  as  available  from  the  source.  Recommendations  for  providing  information  to  the  IID 
include:  i)  developing  an  interface  to  CCS  876  Unicast  data,  ii)  developing  remote  devices  at  four 
key  locations,  networked  to  the  IID,  to  facilitate  manual  data  collection  and  planning  activities 
and  provide  the  only  feasible  source  of  such  data  for  the  IID,  iii)  separate  downloading  of 
systems’  “a  priori”  data  (e.g.,  charts  from  SHINNADS  Dual  Monitor  (SDM))  to  the  IID,  iv) 
maintaining  history  data  in  the  IID,  and  v)  manual  data  entry  into  IID  where  appropriate.  Based 
on  the  completed  IID  Information  Matrix,  we  identify  several  issues  and  suggest  appropriate 
solutions.  Finally,  we  describe  any  outstanding  issues  and  recommend  the  way  ahead. 
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IV 


1  Project  Goals 


1.1  Objectives 

Defence  Research  and  Development  Canada  (DRDC)  Atlantic  has  conducted  a  Cognitive  Work 
Analysis  (CWA)  for  key  Victoria  Class  Submarine  (VCS)  Control  Room  personnel,  leading  to 
the  design  of  the  Information  Integration  Display  (I1D)  to  bring  relevant  data  together  onto  a 
single  screen  that  is  formatted  to  support  Command  decisions. 

This  project  will  investigate  the  feasibility,  likely  level  of  effort  required  and  constraints  of 
acquiring  the  data  required  by  the  I1D  system  from  the  submarine  information  systems.  The  aim 
of  this  contract  is  to  determine  the  scale  of  the  integration  work  required  to  connect  the  developed 
11D  display  to  current  and  near-future  submarine  information  systems,  primarily  the  Submarine 
Command  and  Control  System  (CCS  876),  but  secondarily  the  Central  Surveillance  System 
(CSS),  Autopilot,  Bathymetric  Sampling  System  (BSS),  and  other  systems  as  appropriate,  to 
provide  the  required  data  to  the  display  system. 

Where  required  inputs  are  not  readily  available  or  are  available  from  relevant  sources, 
recommendations  on  the  scope  and  feasibility  of  work  required  to  obtain  data  will  be  determined. 

1.2  Scope 

The  scope  of  this  study  is  constrained  by  the  following  assumptions: 

1.  The  information  requirements  of  the  11D  are  as  identified  in  the  Government  Furnished 
Information  (GFI)  provided  to  Lockheed  Martin  Canada  (LMC)  by  DRDC  Atlantic,  primarily 
references  [1],  [2]  and  [3]. 

2.  In  conjunction  with  the  project  Scientific  Authority,  it  was  decided  to  limit  consideration  of 
future  information  systems  to  systems  already  out  for  contract.  As  for  soon  to  be  obsolete 
systems,  like  the  legacy  Autopilot  and  legacy  Surveillance  System,  LMC  emphasized  instead 
their  planned  replacements,  the  next  generation  Autopilot  and  CSS,  respectively. 

3.  In  determining  the  systems  from  which  the  required  IID  information  is  available,  if  multiple 
options  exist,  preference  will  likely  be  given  to  systems  not  yet  implemented,  where  there 
may  be  the  greatest  likelihood  of  influencing  system  design  to  accommodate  necessary 
changes  to  support  the  IID. 

4.  Throughout  the  report,  we  refer  to  SHINNADS  Dual  Monitor  (SDM).  Unless  specified 
otherwise,  we  are  not  making  any  distinction  between  it  and  related  system  names  like 
“SHINNADS”  and  “Electronic  Chart  Precision  Integrated  Navigation  System  (ECPINS)”. 
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2  Methodology 


In  order  to  fulfil  the  project  objectives,  the  project  investigations  were  conducted  in  the  following 
primary  tasks: 

1.  Task  1  -  Identify  the  information  types  needed  for  the  11D. 

2.  Task  2  -  Investigate  potential  sources  for  the  information  types,  and  specify  the  properties  of 
the  information  types  both  as  used  by  the  IID  and  as  produced  by  the  sources. 

3.  Task  3  -  Based  on  the  findings  of  the  first  two  tasks,  identify  problems  and  recommend 
potential  solutions. 

The  results  of  Tasks  1  and  2  were  recorded  in  the  “IID  Information  Matrix”  described  in  more 
detail  in  Section  3.1. 

The  specific  methodology  used  for  each  of  these  tasks  is  described  in  the  following  sub-sections. 

2.1  Task  1  -  Identify  the  Information  Types  Needed  for  IID 

As  a  starting  point  for  defining  information  types  needed  by  the  IID,  we  listed  in  the  IID 
Information  Matrix  (see  Section  3.1)  all  the  “Information  Requirement”  items  from  the  IID  Area 
description  tables  in  the  IID  Design  Document  (reference  [1]). 

These  items  were  revised  to  provide  more  accurate  definitions  and  descriptions.  New  items 
alluded  to  or  implicit  in  the  Design  Document,  which  had  been  omitted  from  the  IID  Area 
description  tables,  were  added. 

The  “Virtual  Victoria  Data  Model”  (reference  [2]),  “Assumptions  and  Specifications  Matrix” 
(reference  [3]),  and  a  DRDC  Atlantic  demonstration  to  LMC  of  the  prototype  IID  were  used  to 
augment  and  revise  the  list  of  information  types. 

Finally,  the  complete  list  of  information  types  composed  from  the  preceding  steps  included  many 
redundant  items.  These  were  identified  as  such  to  create  a  list  of  unique  information  types.  In  the 
IID  Information  Matrix,  each  of  the  unique  information  types  were  numbered  consecutively  in  the 
order  listed;  redundant  information  types  were  shaded  blue  and  left  unnumbered. 

2.2  Task  2  -  Investigate  Sources  and  Properties  of  the 
Information  Types  Needed  for  IID 

To  the  extent  possible  from  the  IID  documentation  made  available  to  LMC  (references  [1],  [2] 
and  [3]),  the  properties  of  the  information  types  as  needed  by  the  IID  were  entered  in  the  IID 
Information  Matrix.  These  properties  included  units,  resolution,  and  allowed  staleness. 
Originally,  it  had  been  planned  to  include  “accuracy”  of  the  information  as  required  by  the  IID  as 
one  of  the  properties  to  consider.  However,  the  IID  design  documents  made  available  for  this 
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study  did  not  provide  sufficient  insight  into  this  property  to  make  it  worth  including  in  the  1ID 
Information  Matrix.  Furthermore,  although  “allowed  staleness”  was  included  in  the  11D 
Information  Matrix,  there  was  not  much  information  on  this  property  either  in  the  11D  design 
documents  provided. 

LMC  identified  potential  source(s)  of  the  various  information  types  specified  in  the  11D 
Information  Matrix,  determined  if  and  how  this  information  could  be  made  available  to  the  I1D, 
and  in  the  case  of  multiple  sources  for  an  information  type,  suggested  the  prioritization  (Low, 
Medium,  High)  of  the  sources  to  utilize. 

Finally,  we  populated  the  various  fields  in  the  11D  Information  Matrix  regarding  the  properties  of 
the  information  types  as  available  from  the  source.  The  properties  used  are  described  in  more 
detail  in  Section  3.1.  Originally,  it  had  been  planned  to  include  “accuracy”  of  the  information 
produced  by  the  source  as  one  of  the  properties,  but  this  was  omitted  because:  i)  there  is  often 
little  or  no  information  available  on  the  accuracy  of  the  source;  ii)  when  information  is  available, 
it  often  tends  to  be  Classified,  whereas  it  was  intended  to  keep  the  report  Unclassified,  and  iii) 
some  information  types  involve  multiple  systems  (e.g.,  contact  bearing,  which  could  come  from 
bow  sonar,  flank/towed  array  sonar,  passive  ranging  sonar,  periscope,  or  ESM),  each  of  which 
would  have  a  different  accuracy. 

In  elaborating  on  the  various  properties  on  the  I1D  information  types,  if  the  details  of  a  property 
are  not  known  or  unavailable  to  LMC,  it  is  marked  as  “Unk”  (unknown).  Sometimes,  a  particular 
property  is  not  relevant  to  a  particular  11D  information  type,  in  which  case  it  is  marked  as  “N/A” 
(not  applicable). 

2.3  Task  3  -  Identify  Problems  and  Recommend  Solutions 

Based  on  the  11D  Information  Matrix  completed  in  Task  1  and  Task  2,  we  identified  various 
potential  problems  and  observations,  including: 

1.  Issues  or  complications  related  to  the  suggested  source  for  an  IID  information  type,  including 
where  no  practical  source  is  available. 

2.  Cautions,  considerations  or  issues  related  to  suggested  methods  to  make  the  information 
available  from  a  source  to  the  IID,  including  the  feasibility  of  these  methods. 

3.  Incompatibilities  between  the  IID  and  source  properties  related  to  an  IID  information  type, 
e.g.,  where  IID  uses  units  for  data  different  than  the  data  is  provided  by  the  source. 

These  problems  and  observations  are  listed  in  Table  1.  For  each  of  these  problems  and 
observations,  also  shown  in  Table  1  is  LMC’s  recommended  solution. 
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3  Results 


Detailed  information  about  each  specific  1ID  information  type  are  provided  in  the  1ID  Information 
Matrix  described  in  Section  3.1.  Recommended  sources  and  methods  to  make  the  data  available 
to  the  11D  are  described  for  each  11D  information  type  as  part  of  the  matrix.  However,  the  general 
themes  that  emerged  from  the  matrix  regarding  the  sources  for  these  I1D  information  types  are 
described  in  Section  3.2.  Finally,  Section  3.3  lists  issues  observed  from  the  I1D  Information 
Matrix,  and  provides  a  recommended  means  to  resolve  these  issues. 

3.1  IID  Information  Matrix 

The  results  of  Task  1  and  Task  2  investigations  were  recorded  in  an  IID  Information  Matrix,  as 
per  Annex  A. 

In  the  first  two  columns  of  the  IID  Information  Matrix: 

1 .  “No.”  is  the  number  assigned  to  each  unique  information  type. 

2.  “IID  Info  Definition”  is  the  description  of  the  information  type  identified  in  Task  1. 

The  properties  of  the  information  type  as  currently  assumed  or  used  by  the  IID  are  specified  in  the 
IID  Information  Matrix  in  the  following  columns: 

1.  “IID  Display  Ref  (Area)”  indicates  the  specific  IID  Display  Area  that  uses  the  indicated 
information  type. 

2.  “Units”  specifies  the  units  needed  by  the  IID. 

3.  “Resolution”  is  the  least  significant  value  of  the  information  that  is  needed  by  the  IID. 

4.  “Allowed  Staleness”  is  intended  to  be  the  elapsed  time  before  a  refresh  of  the  information 
type  is  required,  as  expected  by  the  IID. 

5.  The  first  “Comment”  column  addresses  notes  and  issues  about  the  information  type 
pertaining  to  its  use  by  the  IID. 

The  properties  of  an  information  type  in  the  submarine  systems  that  can  provide  the  information 
type  are  specified  in  the  IID  Information  Matrix  as  follows: 

1.  “Submarine  System”  is  a  potential  submarine  system  source  for  the  information  type. 
Primary  consideration  was  given  to  systems  that  have  feasible  “Potential  Method(s)  to 
Transfer  Info  to  IID”,  as  identified  in  the  subsequent  field  in  the  IID  Information  Matrix. 

2.  “Publish/Subscribe  Done”  is  specified  as  “Yes”  if  the  identified  system  currently  has  a  means 
to  broadcast  or  make  the  data  available  for  distribution,  and  “No”  otherwise. 
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3.  “Transmission  Format”  is  the  means  by  which  the  information  type  is  transmitted,  specified 
only  when  the  previous  “Publish/Subscribe  Done”  field  is  specified  affirmatively. 

4.  “Potential  Method(s)  to  Transfer  Info  to  IID”  are  LMC’s  suggestions  for  means  whereby  the 
indicated  information  type  could  be  made  available  to  the  IID.  LMC  considered  what  it 
believed  to  be  the  most  promising  methods  to  provide  data  to  the  IID,  with  the  least  impact  on 
systems  and  least  requirement  for  engineering  change. 

5.  “Time  Between  Data  Refresh  Within  System”  is  the  time  between  successive  specifications 
of  the  data  relevant  to  the  information  type  as  it  is  generated  within  the  source  system. 

6.  “Update  Rate  of  Info  Sent  From  System”  is  the  rate  at  which  data  relevant  to  the  information 
type  is  sent  from  the  system. 

7.  “Units”  specifies  the  units  in  which  the  information  type  is  made  available  by  the  source. 

8.  “Resolution”  is  the  least  significant  value  of  the  information  type  data  that  is  provided  by  the 
source. 

9.  “Security  Designation”  is  the  security  level  of  the  information  type  data  provided  by  the 
source. 

10.  “Constraints”  are  special  considerations,  assumptions  or  limitations  relevant  to  the 
information  type  that  exist  for  the  indicated  submarine  system  source  for  that  data. 

11.  “Prioritization  of  Multiple  Systems”  is  LMC’s  recommendation  for  the  relative  prioritization 
of  the  potential  submarine  system  sources  for  the  information  type.  Typically,  this  will  be 
specified  as  “Low”,  “Medium”,  or  “High”. 

12.  The  second  “Comment”  column  addresses  notes  and  issues  about  the  information  type 
pertaining  to  the  designated  submarine  system  source  for  the  information  type. 

In  the  IID  Information  Matrix,  the  purple  text  in  the  “IID  Info  Definition”  column  shows  changes 
to,  or  new  information  types  that  were  not  listed  in,  the  information  requirement  tables  in  the  IID 
Design  Document.  The  purple  text  in  the  first  “Comment”  column  elaborates  on  the  changes  or 
additions  made  to  the  list  of  information  types,  or  points  out  assumptions  to  be  confirmed  or 
questions  to  be  answered  by  DRDC  Atlantic.  The  blue  shaded  rows  are  information  items  from 
the  IID  Design  document  that  were  already  covered  by  a  similar  information  type  elsewhere  in 
the  matrix,  from  one  of  the  other  IID  display  Areas.  Each  of  the  unique  information  types  in  the 
Information  Matrix  is  assigned  a  number  (the  blue  shaded  rows,  indicating  redundant  information 
types,  are  unnumbered). 

3.2  General  Comments  on  IID  Information  Sources 

Sources  specific  to  each  IID  information  type  are  provided  in  the  IID  Information  Matrix.  The 
following  are  general  observations  and  comments  from  consideration  of  all  these  IID  information 
types. 
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1 .  As  indicated  in  the  IID  Information  Matrix,  a  substantial  portion  of  the  information  types  are 
not  currently  routinely  broadcast  or  otherwise  routinely  receivable  by  IID.  This  includes 
sonars,  ESM,  and  many  other  systems  that  pass  data  to  CCS  876.  To  make  information 
available  directly  from  the  systems  that  do  pass  information  to  CCS  876  would  require 
significant  engineering  changes  (ECs)  to  these  individual  systems.  Alternatively,  all  this 
information  can  be  provided  from  one  source,  CCS  876,  with  very  minimal  change. 
Specifically,  CCS  876  has  a  “Unicast”  capability  already  existing  that  provides  real-time 
broadcast  of  all  Data  Gathering  System  (DGS)  data  generated  by  CCS  876.  DGS  data 
includes  most  of  the  relevant  information  from  all  these  reporting  systems.  It  is  accessible 
from  a  simple  Ethernet  connection  (to  existing  ports)  on  a  CCS  876  console,  and 
setup/specification  at  CCS  876  of  the  appropriate  IP  address  at  IID  of  the  port  to  receive  the 
data.  The  only  required  work  to  access  the  data  is  the  development  of  an  interface  module  at 
the  IID  that  would  receive  the  DGS  data,  interpret  it  (DGS  data  is  sent  in  a  defined  message 
format,  as  per  references  [5],  [6]),  and  parse  it  appropriately  for  IID. 

2.  Not  all  CCS  876  data  is  intrinsically  Classified.  However,  in  the  context  of  an  operational 
submarine,  it  is  expected  that  in  general  CCS  876  data,  particularly  the  Unicast  data,  will  be 
Classified. 

3.  For  the  most  part,  there  is  currently  no  routine  connection  or  access  to  repositories  of 
historical  data  relevant  to  the  historical  information  types  (e.g.,  Nos.  72,  97,  113  in  the  IID 
Information  Matrix).  For  example,  some  systems  do  accumulate  history  data,  but  typically 
extensive  engineering  changes  to  these  systems  would  be  required  both  to  access  and 
broadcast  such  data.  Consequently,  it  is  not  currently  practical  to  supply  data  for  the 
historical  information  types  (i.e.,  the  complete  record  of  all  older  data)  directly  from  the 
submarine  systems.  Instead,  it  is  recommended  that  the  IID  maintain  a  historical  database  of 
relevant  data  based  on  the  accumulation  of  “real  time”  versions  of  such  data  that  is  provided 
from  various  sources  to  the  IID. 

4.  There  is  a  variety  of  “a  priori”  data  (charts,  tables,  reference  documents,  threat  sheets,  etc.) 
that  is  the  basis  for  data  needed  by  various  IID  information  types.  Given  the  lack  of  current 
or  easily  implemented  methods  to  provide  most  such  “a  priori”  data  directly  from  various 
submarine  systems  to  IID,  it  is  recommended  to  find  alternative  means  to  make  such 
information  available  to  IID.  The  most  obvious  solution  is  to  simply  separately  load  the  “a 
priori”  data  into  the  IID  as  well  as  the  relevant  submarine  systems.  This  would  of  course 
necessitate  the  development  of  IID  modules  to  hold  and  read  these  databases,  and  format  data 
to  be  used  according  to  the  same  criteria  and  conditions  as  the  systems  on  which  the  “a 
priori”  data  was  originally  installed.  To  some  extent,  this  may  involve  replicating  the  same 
conditions,  or  knowledge  of  these  conditions,  as  on  the  submarine  system  at  the  IID  in  order 
for  the  IID  to  use  the  same  “a  priori”  data.  In  some  cases,  where  the  “a  priori”  data  is  hard¬ 
copy  (e.g.,  paper  charts,  manuals),  it  may  be  necessary  to  convert  this  data  to  a  format  that 
can  be  used  by  the  IID. 

5.  There  are  several  IID  information  types  that  are  used  to  define  scale  or  parameters  for  IID 
display  graphics,  or  control  aspects  of  the  IID  displays  (e.g.,  Nos.  19,  20,  26,  27,  135,  136, 
181).  These  have  been  designated  “IID  Control  Input”  in  the  Source  field  in  the  IID 
Information  Matrix.  If  these  IID  information  types  are  intended  to  be  dynamic  and  cannot  be 
hard  coded  into  the  IID  software,  they  would  need  to  be  done  as  manual  inputs  into  the  IID  as 
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part  of  IID  control.  If  the  IID  intends  to  vary  the  values  for  these  information  types  based  on 
observed  conditions,  then  knowledge  of  some  of  the  other  routinely  sent  IID  information 
types  that  characterize  these  conditions  may  be  required.  On  the  other  hand,  in  most 
instances,  these  parameters  remain  at  the  total  discretion  of  IID  operators,  and  require  no 
information  from  submarine  systems. 

6.  There  are  several  IID  information  types  (e.g.,  Nos.  7,  21,  23,  28,  34—37,  54,  55,  58,  59,  62, 
76,  81,  88-90,  101,  102,  120,  134,  137-139,  141,  143,  144,  146,  150)  that  in  the  IID 
Information  Matrix  have  Submarine  System  designated  as  “Command  Input”  and  Potential 
Method  to  Transfer  Info  to  IID  designated  as  “Manual  Input”.  They  involve  Command 
decisions  and  choices  for  information  types  like  planned  speed,  depth,  etc.  that  are  not 
recorded  electronically  on  any  submarine  system.  Consequently,  they  would  need  to  be 
manually  entered  into  the  IID.  It  is  possible  the  collection/recording  of  this  data  could  be 
accomplished  via  the  “remote  device”  approach  described  in  item  7. 

7.  There  are  many  IID  information  types,  specifically  those  in  the  IID  Information  Matrix  that 
have  Source  specified  as  “Manual  Data  Collection”  (e.g.,  Nos.  3—6,  10,  11,  100,  152—163, 
167,  173,  174)  or  “Planning  Inputs”  (e.g.,  Nos.  121—132),  which  aren’t  really  tied  to  any 
current  submarine  system,  and  for  which  the  only  feasible  method  to  make  data  available  to 
the  IID  would  be  through  manual  input.  However,  we  do  believe  it  is  possible  to  greatly 
improve  the  methods  by  which  this  data  is  collected  or  produced  that  would  make  it 
considerably  easier  for  the  IID  to  acquire  this  information.  The  current  necessity  for  manual 
data  entry  and  the  quantity  of  information  involved  is  overwhelming  to  be  completed  in  just 
one  location.  We  recommended  the  introduction  of  new  “remote  devices”  (e.g.,  tablet, 
laptop)  to  collect  and  produce  the  desired  data  at  the  locations  on  the  submarine  where  the 
relevant  activities  are  most  productively  conducted.  We  see  four  primary 
functionalities/locations  of  use  for  these  remote  devices: 

a.  CO’s  unit  for  Command  inputs,  which  could  be  used  in  the  CO’s  cabin  (with  portability 
as  required).  In  addition  to  providing  Command  with  the  tools  to  plan  missions  and 
schedule  events,  this  remote  access  will  allow  the  CO  to  relay  night  orders,  broadcast 
routine  and  communication  plans,  navigational  ETAs,  mission  orders,  CO  intentions, 
tactical  primary/secondary  objectives,  and  snort  routines. 

b.  A  unit  for  Nav  O,  Ops  O,  and  trainee  inputs,  which  could  be  used  in  the  Wardroom. 
Much  of  the  planning  for  inshore  operations  is  currently  done  on  paper  charts.  The 
remote  device  could  serve  as  a  more  effective  mission  planning  tool,  allowing  the  CO  and 
trainees  to  plan  undisturbed,  save  and  present  their  Command  briefings,  and  make  results 
available  to  IID  as  appropriate. 

c.  Chief  and  PO’s  (C&PO’s)  unit  for  mechanical,  electrical,  Combat  Systems  Engineer’s 
inputs,  which  could  be  used  in  the  C&PO’s  Mess.  Currently,  much  of  the  information 
that  is  needed  by  the  IID  is  recorded  on  “tally  boards”  with  grease  markers.  Mechanical 
information  such  as  fresh  water,  fuel  supplies,  and  battery  dips  (which  would  be  used  to 
calculate  and  update  battery  endurance  estimates  based  on  current  speeds)  are  recorded  in 
logs  outside  of  the  C&PO’s  Mess,  which  is  also  the  ship’s  damage  control  centre  “HQ1”. 
Combat  system  defects,  repairs,  and  system  degraded  implications  could  also  be  entered 
at  this  location  and  transmitted  to  the  IID  for  display  to  Command.  This  would  replace 
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paper  logs/records  as  this  information  could  be  saved  and  backed  up.  In  a  damage 
control  situation,  access  to  appropriate  damage  control  cards  could  be  provided  at  the 
remote  device.  The  IID  in  this  situation  could  be  updated  from  this  unit,  providing  the 
CO  with  vital  real  time  float,  move,  and  fight  data.  As  well,  check  lists  such  as  Open  Up 
for  Dive,  Smoke  Clearance,  and  Damage  Control  Checks  could  also  be  entered  at  this 
location  and  displayed  on  the  IID. 

d.  A  Sound  Room  unit  for  sensors,  tactical  and  classification  inputs,  as  well  as  RCN  range 
prediction  software.  The  remote  entry  device  would  produce  a  ray  path  plot  and  along 
with  the  COI’s  detection/the  sub’s  evasion  depth  based  on  the  current  bathy  could 
immediately  be  transmitted  to  the  IID  display.  The  unit  would  also  allow  for  real  time 
contact  classification  details  to  be  directly  passed  to  the  IID  and  enhance  the  Sound 
Room  record  keeping  abilities  by  allowing  their  data  to  be  saved  to  a  file.  Other 
information  that  could  be  saved  would  eliminate  the  necessity  for  Sound  Room  contact 
and  tape  recording  logs.  COI  threat  sheets,  next  bathy,  atmosphere  monitoring,  and  EW 
danger  levels  would  be  entered  at  the  Sound  Room  location. 

These  remote  devices  would  be  loaded  with  relevant  “a  priori”  information  and  new 
applications  to  support  specific  activities  heretofore  largely  manual  and  paper -based.  For 
example,  an  ECPINS-like  capability  for  chart  data  would  likely  be  required  on  the  CO  and 
Wardroom  units.  These  devices  could  be  networked  as  appropriate  (i.e.,  to  the  IID  to 
exchange  information).  This  scheme  has  the  potential  to  make  the  IID  a  hub  for  planning 
results  and  a  display  point  for  what  is  currently  numerous  paper  records. 

Transitioning  such  activities  to  a  remote  device  would  make  them  more  efficient,  more 
accurate,  allow  a  detailed,  consistent,  permanent  record  to  be  maintained,  and  provide  a 
simple  means  to  provide  information  needed  by  the  IID  but  likely  not  otherwise  easily 
available  to  it.  The  remote  devices  would  also  reduce  the  personnel  traffic  in  the  Control 
Room.  Effort  would  be  required  to  define  and  develop  the  applications  for  the  appropriate 
remote  devices,  and  define  and  implement  the  appropriate  network  connections  to  IID. 
However,  the  network  requirements  would  be  fairly  minimal,  and  could  be  integrated  with 
other  required  network  infrastructure  upgrades  being  planned  for  the  submarines.  Lockheed 
Martin  has  been  involved  in  such  network  studies,  as  per  reference  [7].  Furthermore,  there 
would  be  negligible  impact  on  other  current  submarine  systems,  and  no  need  for  potentially 
complicated  and  costly  ECs  to  these  systems. 

8.  There  did  not  appear  to  be  any  explicit  mention  of  the  use  of  Automatic  Identification  System 
(A1S)  in  the  information  types  elaborated  in  reference  [1],  apart  from  how  they  could  be  used 
to  contribute  to  general  contact  related  information  types  (e.g.,  contact  position).  Currently 
on  the  submarine,  AIS  data  is  received,  but  not  systematically  integrated  (apart  from  possible 
manual  input)  into  the  contact  data  processed  by  CCS  876.  When  used,  a  dedicated  AIS 
view/layer  is  presented  (e.g.,  on  SDM).  Consequently,  in  the  definition  of  IID  information 
types  in  the  IID  Information  Matrix,  a  separate  AIS  IID  information  type  was  included,  and  it 
is  recommended  that  it  be  incorporated  in  the  Area  4  display  as  an  independent  layer.  Since 
the  AIS  data  is  not  integrated  into  CCS  876  contacts,  it  is  probably  not  productive,  and 
perhaps  even  misleading,  for  the  IID  to  attempt  to  associate  or  fuse  the  AIS  data  with  current 
CCS  876  contact  data  as  part  of  the  contact-related  IID  information  types  (for  position, 
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course,  speed,  etc.).  A  suitable  A1S  interface  would  need  to  be  developed  for  the  1ID,  and  I1D 
displays  appropriately  updated  to  incorporate  A1S  data  as  suggested. 

3.3  Analysis  of  IID  Information  Matrix 

Table  1  below  describes  some  of  the  principal  issues  (and  their  recommended  solutions)  from  the 
IID  Information  Matrix.  The  IID  Information  Matrix  should  be  examined  directly  for  the 
discussion  of  issues  relevant  to  each  individual  IID  information  type. 


Table  1:  Issues  from  Information  Matrix  and  Recommended  Solutions. 


No. 

Issues  and  Observations 

Recommended  Solution 

1. 

Geographic  plots  will  need  ownship  and 
target  course  and  speed  data  specified  w.r.t. 
ground,  while  conventional  tactical  plots 
(e.g.,  like  those  on  CCS)  will  require 
ownship  and  target  course  and  speed 
specified  w.r.t.  the  water  mass  in  which  the 
submarine  resides  (with  the  assumption  that 
all  platforms  in  the  water  mass  experience 
the  same  movement  of  the  water  mass). 

Area  4  related  information  types  will  be 
specified  w.r.t.  ground,  while  most  of  the 
remaining  Area  displays  will  use 
information  types  specified  w.r.t.  water 
mass. 

2. 

Accurate  data  for  ownship  course  and  speed 
w.r.t.  ground,  as  well  as  latitude/longitude 
position,  may  be  problematic  when  dived. 

Ownship  course  and  speed  w.r.t.  ground 
will  rely  on  INS/GPS  data.  When  GPS  data 
is  available  (e.g.,  when  submarine  is  at 
periscope  depth  or  above),  INS/GPS  is  quite 
accurate.  However,  when  dived,  GPS  is  not 
available,  and  only  the  course  and  speed 
w.r.t.  water  mass  is  precisely  measured, 
while  course  and  speed  w.r.t.  ground  must 
be  determined  using  estimates  for  speed  and 
direction  of  the  water  mass  (including  from 
tables/charts  of  current).  Consequently, 

INS  data  for  position  may  be  of  limited 
accuracy.  This  is  all  part  of  the  “Pool  of 
Error”  estimate  integrated  into  SDM,  which 
itself  may  evolve  pending  possible  future 
upgrades  to  SDM. 
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No. 

Issues  and  Observations 

Recommended  Solution 

3. 

Contact  position  on  submarine  systems  is 
never  shown  in  the  context  of  geographic 
plots,  i.e.,  in  latitude/longitude  plots  (with 
the  exception  of  when  contacts  are  part  of 
independently  presented  A1S  data).  Instead, 
contact  position  is  shown  w.r.t.  ownship  on 
what  amounts  to  a  locally  flat  Cartesian 
coordinate  system. 

To  present  CCS  determined  contact  position 
data  on  a  geographic  plot,  it  would  be 
necessary  to  add  a  module  to  IID  that  could 
convert  CCS  contact  position  data  to 
latitude/longitude.  Knowing  ownship 
latitude/longitude  (from  ownship  data) 
would  allow  orientation  of  the  contact  data 
within  a  geographic  plot,  and  then  suitable 
conversion  of  Cartesian  flat-earth  data  on  a 
contact  to  a  curved  coordinate  system  would 
be  required  to  determine  latitude/longitude 
of  the  contacts.  However,  it  should  be 
noted  that  when  dived,  the  inherent 
inaccuracy  of  ownship  data  will  also 
translate  to  similar  inaccuracy  in  the 
converted  contact  position  data. 

4. 

The  information  type  for  “Air  Quality”  (No. 
3)  was  not  specific  about  what  aspects  of  air 
quality  would  be  reported. 

02,  C02  and  pressure  leveles  can  be 
routinely  monitored  on  Analox;  CO  levels 
can  be  monitored  by  Draeger  tubes  during 
damage  control. 

5. 

LMC  noted  several  IID  information  types 
(Nos.  41,  83,  84,  159,  160)  that  were 
included  in  the  Virtual  Victoria  Data  Model 
(reference  [2])  for  which  there  was  no 
relevant  description  in  the  IID  Design 
Document  (reference  [1]). 

These  information  types  were  included  in 
the  IID  Information  Matrix. 

6. 

The  IID  Design  Document  (reference  [1]) 
tends  to  use  “contact”  and  “COI” 
interchangeably  for  many  of  its  information 
types,  when  in  fact  the  COIs  are  a 
designated  set  of  contacts,  which  are 
therefore  a  subset  of  all  contacts. 

Unless  otherwise  specified,  we  have  treated 
those  IID  information  types  listed  as 
“contact/COI”  in  the  description  as  applying 
in  general  to  a  contact.  Information  type 

No.  146  is  a  Boolean  that  can  be  used  to 
designate  whether  a  given  contact  has  been 
identified  as  a  COI. 

7. 

The  IID  Design  Document  (reference  [1]) 
tends  to  refer  to  information  types  as 
“relative  bearing”  (Nos.  93,  104,  105,  110) 
in  instances  that  really  involve  what  is 
designated  as  “true  bearing”  in  sensors/CCS 
terminology. 

These  information  types  have  been  re¬ 
labeled  as  “true  bearing”,  and  the  sources 
that  supply  them  also  consider  true  bearing. 
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No. 

Issues  and  Observations 

Recommended  Solution 

8. 

IIP  information  type  No.  140  deals  with 
“Sensors  holding  contact”.  However,  there 
is  no  simple  way  to  provide  access  to  data 
directly  from  sensors.  Furthermore,  even 
the  concept  of  a  primary  “reporting”  sensor 
is  not  really  used  or  maintained  in  CCS, 
apart  from  perhaps  a  verbal  instruction  to  an 
operator  to  stop  cutting  contacts  through  to 
CCS.  A  similar  issue  is  involved  in  the 
determination  of  “Previous  Sensor  Fixes” 

(No.  97). 

DRDC  should  clarify  the  intended  purpose 
of  this  information  type.  If  it  is  sufficient  to 
know  what  sensors  are  cutting  data  to  CCS, 
this  can  be  fairly  easily  interpreted  from  the 
proposed  11D  use  of  CCS  876  Unicast  data 
by  just  monitoring  what  sensor  data  is  being 
updated  in  the  Unicast  message  stream. 

Any  other  interpretation  requiring  access 
directly  to  sensor  data  would  be  difficult  to 
implement. 

9. 

Unlike  the  weapons  status  data  that  is 
available  to  CCS  876  via  the  Weapon 

System  Data  Bus,  there  is  no  equivalent 
broadcast  of  SSE  status  data.  Consequently, 
there  is  no  convenient  method  to  convey 

SSE  related  data  directly  to  11D. 

SSE  status/inventory  will  only  be  available 
to  1ID  by  manual  input  or  manual  data 
collection. 

10. 

There  is  an  HD  information  type  (No.  119) 
that  represents  the  sonar  waterfall  display. 

At  best,  if  the  waterfall  display  video  could 
be  output  from  the  sonar,  there  would  be  no 
way  to  present  only  the  waterfall  portion 
and  exclude  the  menus  that  are  also  a  part  of 
the  video  display. 

If  the  waterfall  displays  are  required,  it  will 
probably  be  necessary  to  include  the  menus 
that  are  part  of  these  sonar  displays. 

11. 

No  suitable  source  of  altitude  is  currently 
available.  Consequently,  the  “contact 
altitude”  1ID  information  type  (No.  84)  has 
no  source  for  data  in  a  submarine  system. 

At  best,  an  operator  or  Command  estimate 
could  be  made  about  contact  altitude  and 
manually  input  to  IID. 

12. 

Contact  behaviour  is  not  analyzed  or 
maintained  systematically  or  in  any 
automated  manner  by  current  submarine 
systems.  Consequently,  there  is  no  source 
for  I1D  information  types  “COl  change 
behaviour”  (No.  106)  and  “Contact/COl 
recent  behaviour”  (No.  1 14). 

The  raw  contact  data  that  can  be  used  to 
perform  the  situation  assessment  to 
determine  contact  behaviour  is  potentially 
provided  to  IID  (via  CCS  876  Unicast).  It  is 
therefore  feasible  to  develop  modules  in  the 
IID  that  would  perform  the  requisite 
behaviour  analysis. 

11 


No. 

Issues  and  Observations 

Recommended  Solution 

13. 

In  CCS  876,  tracks  either  are  or  are  not 
included  on  the  Threat  Tote  (up  to  8  tracks 
can  be  assigned).  No  attempt  is  made  to 
assign  a  quantitative  threat  value  or  relative 
ranking  of  the  threats.  Consequently,  there 
is  no  source  for  11D  information  type 
“Threat  level  associated  with  COI”  (No. 

115)  beyond  a  simple  “threat/not  a  threat” 
designation  for  a  contact. 

Apart  from  whether  or  not  a  contact  is  on 
the  CCS  Threat  Tote,  any  relative  or 
quantitative  evaluation  of  the  threats  would 
have  to  be  done  in  an  IID  module  using  the 
CCS  876  Unicast  data  potentially  available 
to  11D.  The  only  alternative  would  be 
Command  designations  about  threat  level 
that  would  be  manually  input  to  the  IID. 

14. 

We  noted  minor  differences  in  many  of  the 
information  types  between  the  units  for  data 
as  needed  by  the  11D  and  the  units  in  which 
the  data  is  provided  by  the  system  source. 
Common  examples  of  the  variations  are 
metres  vs.  feet,  Nautical  Miles  vs.  yards, 
degrees  vs.  radians,  and  Knots  vs.  yards/sec. 

These  are  simple  unit  conversions  that 
should  be  coded  as  part  of  the  IID  interface 
modules  that  receive  and  process  the  data 
provided  by  the  submarine  system  sources. 

15. 

IIP  information  types  No.  86  and  87  present 
data  at  the  1ID  in  hours,  but  the  source 
information  is  measured  as  a  percentage. 

To  present  the  required  units  for  the  data  at 
the  IID  (i.e.,  in  hours),  in  addition  to  the 
measured  source  data  (specified  as  a 
percentage),  it  will  be  necessary  to  have  a 
baseline  value  for  total  battery  capacity  to 
make  the  conversion  to  hours. 

16. 

No  bathy  and  ray  path  plot  history  data  is 
maintained  for  the  11D  in  the  available 
design  documents. 

We  have  proposed  means  to  make  bathy/ray 
path  data  available  to  the  IID.  It  is 
recommended  that  a  historical  record  of  this 
data  be  maintained  by  the  IID. 
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4  Conclusions 


4.1  Summary  of  Findings 

An  IID  Information  Matrix  was  produced  (see  Annex  A)  that  describes  183  unique  information 
types  needed  by  the  IID.  For  each  of  these,  we  identified  potential  submarine  system  source(s), 
recommended  method(s)  to  make  this  information  available  to  the  IID,  and  listed  properties  of  the 
information  types,  both  as  needed  by  the  IID  and  as  available  from  the  source. 

The  primary  areas  of  new  development  to  support  making  important  information  available  to  the 
IID  are: 

1.  Provide  an  interface  module,  likely  best  suited  as  part  of  the  IID  software,  which  would 
receive,  interpret  and  parse  CCS  876  Unicast  data.  This  interface  is  not  a  complicated 
programming  problem  (a  related  parser  has  been  developed,  as  per  reference  [5],  for  other 
tasks),  yet  would  make  available  to  IID  almost  any  data  processed  by  CCS  876  (including 
most  of  the  data  passed  to  it  from  sensors  and  weapons). 

2.  Introduce  several  remote  devices  (e.g.,  tablet  or  laptop),  and  develop  relevant  applications  for 
them,  to  provide  data  for  IID  information  types  that  would  require  manual  data  collection  or 
result  from  planning  activities  whose  results  would  otherwise  not  be  available  to  the  IID. 

3.  Modify  the  IID  software  to  read,  store,  and  display/process  as  needed  data  corresponding  to 
“a  priori”  information  supplied  to  various  submarine  systems  that  is  also  needed  by  IID.  This 
“a  priori”  data  should  be  loaded  onto  IID  separately  when  also  loading  on  the  originally 
intended  submarine  systems.  In  addition,  it  may  be  beneficial  to  convert  data  that  currently 
exists  only  in  a  hardcopy  format  to  an  electronic  format  that  could  be  used  as  needed  on  the 
IID,  or  the  suggested  remote  devices. 

4.  Modify  the  IID  software  so  that  all  historical  data  needed  by  the  IID  can  be  stored  internally 
to  the  IID.  Where  there  is  a  stated  need  for  historical  data,  means  have  been  suggested  to 
make  the  real-time  versions  of  this  data  available  to  IID.  IID  shoidd  be  suitably  modified  to 
record,  maintain,  and  access  this  data  as  needed. 

5.  Provide  for  manual  entry  into  the  IID  of  appropriate  data,  including  most  Command  inputs, 
information  that  cannot  be  otherwise  feasibly  obtained  from  submarine  systems,  and  data  that 
is  specifically  intended  as  IID  control  inputs  separate  from  any  submarine  system. 

6.  Introduce  AIS  data  into  the  IID  geographic  display  (Area  4)  as  a  distinct  layer,  separate  from 
other  CCS  based  contact  data  that  is  displayed. 

An  analysis  of  the  IID  Information  Matrix  pointed  out  a  variety  of  potential  issues  about  the  IID 
information  types  and  how  to  make  the  data  for  them  available  to  the  IID.  These  issues  are  listed 
in  Table  1.  Also  provided  in  this  table  is  a  recommended  solution  for  each  of  these  issues. 
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4.2  Discussion  of  Outstanding  Issues 


The  following  are  issues  that  arose  from  this  study,  but  for  which  there  were  no  specific  LMC 
recommendations  to  resolve: 

1.  Not  much  information  was  available  in  the  IID  reference  documentation  made  available  to 
LMC  concerning  the  “Allowed  Staleness”  of  the  various  information  types  as  needed  by  the 
IID,  so  this  field  is  largely  designated  as  Unknown  in  the  IID  Information  Matrix. 

2.  The  IID  information  type  properties  of  accuracy  of  the  information  type  needed  by  the  IID 
and  accuracy  of  the  information  as  provided  by  the  source  were  eliminated  from 
consideration  due  to  lack  of  information  in  the  available  IID  design  documentation  for  the 
former,  and  because  of  the  difficulty  in  accessing  the  information  and  Classified  nature  of  the 
data  when  it  is  available  for  the  latter.  Consequently,  no  inconsistencies  between  accuracy 
needed  by  IID  and  accuracy  available  from  source  were  examined.  If  this  is  critical 
information,  then  it  will  be  necessary  to  acquire  more  detailed  documentation  on  both  the  IID 
design,  and  performance  specs  and  analysis  on  the  submarine  information  sources. 

3.  No  practical  source  of  infonnation  is  available  for  the  following  IID  information  types: 

a.  Contact  altitude  (No.  84  in  the  IID  Information  Matrix). 

b.  COI  change  behaviour  (No.  106). 

c.  Contact/COI  recent  behaviour  (No.  114). 

d.  Threat  level  associated  with  COI  (No.  115). 

For  items  b  through  d,  if  the  IID  adopts  the  recommended  use  of  CCS  876  Unicast  data,  then 
all  the  raw  data  would  be  available  to  develop  appropriate  situation  and  threat  assessment 
modules  as  part  of  the  IID  to  make  these  types  of  evaluations  possible  as  part  of  IID  function. 

4.  Lack  of  documentation  on  SDM  limits  the  insight  LMC  can  provide  on  the  use  of  SDM  as  a 
source  for  relevant  IID  information  types,  the  methods  by  which  information  can  be  made 
available  from  SDM,  and  the  properties  of  the  SDM-related  IID  information  types.  However, 
LMC  has  sufficient  fundamental  understanding  of  SDM  that  our  key  recommendations  and 
conclusions  regarding  sources  and  methods  of  availability  for  IID  information  types  that 
coidd  potentially  involve  SDM  would  not  be  substantially  altered.  In  particular,  items  4  and 
7  in  Section  3.2  present  alternative  approaches  for  supplying  information  to  the  IID  that 
might  otherwise  have  to  be  drawn  from  SDM. 

5.  For  those  IID  information  types  that  have  the  source  listed  as  SDM,  it  should  be  recognized 
that  there  is  no  simple  way  to  make  SDM  data  electronically  available  to  IID.  In  some  cases, 
data  thought  of  as  SDM-related  has  already  been  alternatively  sourced  in  the  IID  Information 
Matrix.  For  example: 

a.  “a  priori”  data  held  at  SDM  (e.g.,  charts)  could  alternately  be  loaded  on  IID  when  loading 
on  SDM. 
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b.  External  data  read  into  SDM  can  simultaneously  be  read  into  I1D,  e.g.,  A1S. 

c.  Some  planning  capabilities  that  use  or  produce  information  that  could  appear  on  SDM 
may  be  more  suitably  done  on  remote  devices,  as  discussed  earlier. 

However,  where  there  is  no  reasonable  alternative  to  SDM  for  the  I1D  to  acquire  data,  it 
should  be  noted  that  there  are  immediate  plans  for  a  hardware  upgrade  to  SDM.  This  may 
provide  an  opportunity  for  suitable  ECs  to  SDM  to  make  any  necessary  data  available  to  I1D. 
A  further  investigation  would  need  to  be  conducted  on  the  scope  of  changes  to  be  made  to 
SDM,  and  whether  changes  required  for  I1D  could  be  accommodated.  In  the  interim,  any 
information  needed  from  SDM  would  likely  have  to  be  obtained  via  manual  input. 
Fortunately,  our  other  recommended  courses  of  action  for  obtaining  data  related  to  the  I1D 
have  minimized  this  requirement. 

6.  LMC  reviewed  high  level  documents  for  the  CSS  (e.g.,  reference  [4]),  but  there  was  not  much 
detail  in  the  available  documentation  about  new  subsystems  that  might  be  integrated  to  the 
CSS  and  have  data  that  may  be  relevant  to  the  IID.  Most  of  our  projections  about  the  CSS  as 
as  a  source  of  data  and  the  means  to  provide  it  to  the  IID  are  based  on  our  working 
knowledge  of  the  current  Surveillance  System  and  the  general  information  in  the  indicated 
reference  documents.  As  more  detailed  design  and  interface  specifications  for  the  CSS  come 
available,  it  may  be  feasible  to  update  the  methods  to  provide  data  to  the  IID  for  a  few  of  the 
relevant  IID  information  types.  Regardless,  in  the  IID  Information  Matrix,  any  information 
type  for  which  the  Source  is  specified  as  “CSS”  will  likely  require  additional  design  changes 
to  the  CSS  to  enable  such  information  to  be  output  to  the  IID. 

4.3  Recommended  Way  Ahead 

The  following  items  are  LMC’s  primary  recommendations  for  the  way  ahead  in  providing 

information  from  submarine  systems  to  the  IID: 

1.  Implement  an  interface  to  CCS  876  Unicast,  likely  as  a  module  within  IID  software. 

2.  It  was  recommended  that  several  “remote  devices”  (e.g.,  tablet,  laptop)  should  be  introduced 
to  provide  data  for  IID  information  types  related  to  manual  data  collection,  some  planning 
activities,  etc.,  as  described  in  the  IID  Information  Matrix.  It  is  suggested  that  there  probably 
should  be  a  more  general  investigation  of  various  submarine  activities  and  processes  that 
coidd  benefit  from  various  automated  support  tools  on  remote  devices,  for  which  the 
applications  and  devices  needed  for  IID  would  be  an  important,  but  properly  coordinated, 
subset.  This  would  obviously  benefit  the  IID  in  that  data  for  IID  information  types  that  might 
not  otherwise  be  available  would  be  provided.  However,  it  would  simultaneously  improve 
the  capabilities  and  performance  of  the  applications  transferred  to  and  performed  on  these 
remote  devices,  and  thereby  benefit  overall  VCS  performance. 

3.  Develop  a  suitable  interface  for  the  IID  to  be  able  to  receive  AIS  data,  and  update  the  IID 
displays  to  be  able  to  incorporate  the  AIS  data  as  suggested  in  Section  3.2  item  8. 
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4.  Determine  whether  there  are  any  indicated  sources  of  “a  priori”  data  (particularly  those  that 
may  exist  only  in  a  hard-copy  format)  that  should  be  converted  to  a  format  that  is  useable  by 
the  I1D,  and  develop  an  appropriate  interface  for  the  1ID  to  use  this  data. 

5.  LMC  is  currently  implementing  a  significant  upgrade  to  the  Tactical  Weapons  Systems 
Trainer  (TWS)  in  S17  at  CFB  Halifax,  to  be  completed  in  FY13/14.  The  primary  objective 
for  the  upgrade  is  to  facilitate  overall  integration  testing  of  current  fitted  systems  with  future 
Combat  Systems  ECs.  Once  the  upgrade  is  complete,  the  TWS  would  be  an  ideal  location  to 
develop  and  validate  the  proposed  methods  to  make  information  required  by  the  I1D  available 
from  submarine  systems.  This  would  hold  especially  for  next  generation  systems  that  will  be 
available  for  testing  in  the  TWS  prior  to  any  other  venue.  Furthermore,  the  Submarine 
Division  staff  and  students  could/would  readily  provide  feedback  on  concepts  in  aid  of  any 
formal  project  progression.  It  is  recommended  that  in  the  short  term  (within  the  next  FY) 
DRDC  Atlantic  undertake  to  produce  prototype  IID  hardware  and  software  to  fit  in  the  TWS, 
and  develop  the  Unicast  interface  that  will  ultimately  take  data  from  the  CCS  876  Tech 
Refresh  System  to  be  installed  in  the  TWS  Q2  14.  At  the  same  time,  other  suggested 
methods  to  utilize  system  sources  available  in  the  TWS  can  be  investigated  and  developed  as 
appropriate.  This  work  could  be  done  in  parallel  with  the  VCS  backbone  refresh  currently 
being  designed  by  Lockheed  Martin. 

6.  Consideration  could  be  given  to  the  following  three  fitted  sensor  systems  (with  recommended 
upgrades  in  bold)  for  input  to  the  IID  through  the  Combat  System  LAN : 

a.  2004  Sound  Velocity  (SV)  Meter  upper/lower  sound  (A-D  both  outputs  broadcast  to 
CS  LAN). 

b.  Ownship  Noise  (OSN)  Hydrophones  discrete  data  (A-D  all  outputs  broadcast  to  CS 
LAN). 

c.  189  Cavitation  Indicator  (A-D  single  output  broadcast  to  CS  LAN). 

Individually,  these  upgraded  continuous  outputs  would  provide  significant  platform  self  and 
situational  awareness,  presumably  a  goal  of  the  IID.  A  simple  combing  algorithm  could  be 
developed  to  add  considerably  more  value. 
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Annex  A  IID  Information  Matrix  File 


The  results  of  Tasks  1  and  2  were  recorded  in  the  IID  Information  Matrix.  A  description  of  the 
fields  used  to  organize  these  results  is  provided  in  Section  3.1. 
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New.  IID  Design  document  shows  the  Area 

5  Range  view  has  a  velocity  vector  as  part  of 
the  contact/COI  symbol,  which  will  require 
contact/COI  course  &  speed  (w.r.t.  water 
mass)  info. 

New.  IID  Design  document  shows  the  Area 

5  Range  view  has  a  velocity  vector  as  part  of 
the  OS  symbol,  which  will  require  OS  course 

6  speed  (w.r.t.  water  mass)  info. 

Described  as  being  the  centre  of  the  plot 
which  did  not  seem  to  be  a  geographic  plot 
(therefore  no  data  should  be  needed),  but 
Design  Doc  indicated  that  it  uses  Lat/Long 
from  ECPINS? 

Confirm  "bearing"  should  be  ''course'. 

Assume  Course  is  w.r.t.  Water  Mass. 

IID  Design  Doc  has  source  specified  as 

Sonar.  We  will  assume  can  be  interchanged 
with  SFCS. 

See  comment  about  "relative”  bearing  in 

Area  5  -  Rel  Rng  (Contact/COI  relative 
bearing). 
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r 

1 

Range  of  stem  arc  available  from  Stern  Arc  1 

Operating  Procedures  (STOPS). 

Normally  uses  "true",  not  "relative"  bearing 
(even  in  a  relative  plot). 

Normally  uses  "true”,  not  "relative"  bearing 
(even  in  a  relative  plot). 

New.  IID  Design  document  shows  the  Area 

5  Bearing  view  has  NATO  symbology  for  the 
contact/COI,  which  will  require  classification 
data  to  choose  appropriate  symbol. 
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speed  w.r.L  water  mass 
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Comment 

TheContact  uncertainty  is  transmitted  via  UNICAST  to 
a  determined  IP  address.  This  data  would  be  available 
in  the  Threat  Message  identified  as  "Bearing  Error” 
using  a  32-bit  floating  point  number. 

Direct  Video  feed  from  PRS/BSSU/2046. 

The  Weapon  state  is  transmitted  via  UNICAST  to  a 

determined  IP  address.  This  data  would  be  available 

in  the  MK48  Mod4  Telcom  Message  identified  as 

"Exploder  Armed"  using  a  32-bit  flag  representing  True 

Ifhe  Warning  Depth  would  be  entered  by  Command.  1 

The  classification  confidence  level  are  roughly 

determined: 

If  classified  visual  +  EW,  Intercept  or  sonar  (BB, 

LOFAR,  DEMON).  100%  (i.e.  CERT) 

If  classified  visual  only  (range,  weather,  or  time  of  day 

factors  in),  85%  (i.e.  PROB) 

If  classified  sonar  (BB)  +  EW  or  LOFAR,  75%  (i.e. 

PROB) 

If  classified  sonar  (BB)  +  intercept  or  DEMON,  60% 

(POSS) 

If  classified  sonar  (BB)  only,  40%  (ie  POSS). 

1  Information  will  be  provided  by  Sound  Room. 
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Comment 

It  is  called  uncertainty  in  "bearing”,  but  the 
description  refers  to  it  as  "course". 

What  sonars  are  displayed  (only  Bow  Sonar, 
orPRS,  Flank,  etc.)?  Only  waterfall  display? 
Only  one  display  per  sonar?  Video  or  digital 
feed? 

If  video  feed,  will  it  include  the  whole  sonar 
display,  including  any  menus,  as  opposed  to 
just  the  waterfall  display?  In  addition,  is  it 
possible  the  video  feed  could  be  shifted 
away  from  a  waterfall  display? _ 

Extracted  from  Area  4  planned  route. 

Changes  in  course  w.r.t.  Ground,  and  depth.  1 

Likely  taken  from  same  source  as  "Details  of  1 

snortino  plan". 

Likely  taken  from  same  source  as  "When  to  1 

Area  3  'Time  of  next  BATHY  firing"  will  be  1 
needed  to  compute  this  value. 

Specifies  whether  or  not  the  weapon  is 

May  need  to  clarify  what  exactly  is  meant  by 
"armed”  (e.g.,  Safe/Fire  key  set  to  Fire?). 

Charted  Depth  is  compared  to  a  depth 
warning  value.  Also  need  to  specify  the 
warning  depth. 

This  is  refers  to  Priority  1  and  2  alarms,  and 

Is  a  different  source  for  depth  than  in  Area  3. 

New.  Used  by  Depth  of  Water  alert. 

We  assume  these  alerts  are  based  on 
contact  or  COI  information  determined 
elsewhere. 

New.  When/if  alert  has  been  acknowledged, 
as  suggested  by  Virtual  VIC  Data  Model. 

New.  When/if  alert  has  ended,  as  suggestedl 

by  Virtual  VIC  Data  Model. 

New.  IID  Design  Doc  tends  to  use  "contact" 
and  "COI”  interchangeably,  when  in  fact  a 
"COI”  is  a  particular  type  of  contact  we  want 
to  investigate.  Therefore,  we  need  a  list  to 
specify  what  COIs  should  be  considered. 

Uses  other  reports  of  Contact  Speed, 

Course  and  Bearing.  Could  use  reports  from 
Sonar  or  SFCS. 

Assume  this  is  just  a  sort/filter  on  info 
already  provided  to  IID. _ 

In  what  format  is  uncertainty  in  classification 
used  in  IID  (confidence  level,  qualitative, 
discrete/continuous,  etc.)? 

Assume  the  vitals  are  measured  values  1 

(e.g.,  from  sound  room). 
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Comment 

Information  will  be  provided  by  Sound  Room. 

Information  will  be  provided  by  Sound  Room. 

This  information  would  be  entered  into  the  IID  from 

various  reference  materials. 

1  Determined  by  Command 
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Comment 

There  will  be  a  difference  between  sensors 
that  are  receiving  data  on  the  contact,  which 
would  be  available  only  at  the  sensor  level, 
and  sensors  that  are  reporting  on  the 
contact,  i.e.,  sending  cuts  over  to  SFCS. 

The  latter  would  be  much  easier  to  provide 
to  IID,  but  there  would  be  no  way  of  knowing 
when  SFCS  is  not  receiving  reports  (e.g., 
sensor  told  to  cease  reporting)  but  the 
sensor  still  has  contact. 

"show  when  ownship  Is  in  sensor  range” 
means  when  ownship  is  in  range  of  contact's 
sensors.  Seems  to  involve  info  types  for 
range  from  OS  to  COI,  counterdetection 

Not  clear  what  exact  display  pops  up.  and 
what  info  is  displayed  (although  likely  to  just 
involve  existino  info  available  to  IID). 

"ownship  is  in  weapons  range"  means 
ownship  is  in  range  of  contact's  weapons,  so 
COI  weapons  range  info  will  also  be  needed 
here  to  determine  when  to  show,  as  with 

Area  4,  Area  5-Rel  Rng,  Area  5-Rel  Brg, 

Area  5-Brg  Rate,  Area  8-COI.  Will  also  need 
info  type  for  range  between  OS  and  COI. 

New.  To  generate  the  list  of  COIs 
information  type  in  the  preceding  item,  we 
will  also  need  the  acutal  "mission 
documentation".  Note  that  the  COI  list  is 
covered  in  Area  8-Contact  Mgt. 

New.  T/F  setting  as  to  whether  contact  is  1 

COI,  as  per  Virtual  VIC  Data  Model. 

This  has  been  supplanted  by  the  "Notes"  and 
"COI  Details"  info  types  added  below,  which 
were  specified  in  the  Virtual  VIC  Data  Model. 

New.  Any  notes  specific  to  the  contact,  as 
per  Virtual  VIC  Data  Model. 

Clarify  whether  these  Notes  are  available  for 
any  contact,  or  only  contact  designated  as 
COI. 

New.  Details/records  related  to  the  COI,  as  1 

per  Virtual  VIC  Data  Model. 

Looks  like  this  will  draw  on  a  variety  of  other 
established  info  types.  Likely  to  be  threat 
database  and  TOTE. 

Will  also  need  'COI  counterdetection  ranges' 
[Area  4,  Area  5-Rel  Rng,  Area  5-Rel  Brg, 

Area  8-COI]  to  determine  when  to  show. 

Not  sure  what  info  is  displayed  and  the 
format  of  the  display. 

Will  need  Area  8  (COI  weapons  ranges)  to 
determine  when  to  display  this. 

Not  sure  of  the  format  of  the  display  or  the 
information  to  be  Dresented  in  the  disDlav. 

New.  Moon  visibility  (New  through  Full),  as 
suggested  by  Virtual  VIC  Data  Model,  but  not 
clear  if  used  by  IID. 

New.  Whether  moon  is  "waxing"  or 
"waning",  as  suggested  by  Virtual  VIC  Data 
Model,  but  not  clear  if  used  by  IID. 
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Comment 

The  Weapon  State:Tube  Number  is  transmitted  via 

UNICAST  to  a  determined  IP  address.  This  data 

would  be  available  in  the  Set  Weapon  State  Message 

identified  as  'Tube"  using  a  32-bit  unsigned  integer. 

The  Weapon  State:Mode  of  Weapon  is  transmitted 

via  UNICAST  to  a  determined  IP  address.  This  data 

would  be  available  in  the  Set  Weapon  State  Message 

identified  as  "Exercise"  using  a  32-bitflag.  The  Value 

wouuld  be  represent  either  Normal  or  Exercise  Modes. 

The  Weapon  State:Weapon  Type  is  transmitted  via 

UNICAST  to  a  determined  IP  address.  This  data 

would  be  available  in  the  Tube  Inventory  Message 

identified  as  "Weapon  Type”  using  a  32 -bit  unsigned 

integer.  The  Value  wouuld  be  represent  Empty,  MK48 

Mod4  Warshot,  MK48  Mod4  Exercise,  Watershot, 

MK22,  MK48  ModM  Warshot,  MK48  Mod4M  Exercise, 

MK48  Mod/AT  Warshot  Simulator,  MK48  Mod7AT 

Exercise  Simulator,  MK48  Mod7AT  Warshot  or  MK48 

Mod7AT  Excercise. 

The  Weapon  state:Weapon  enabling  is  transmitted 

via  UNICAST  to  a  determined  IP  address.  This  data 

would  be  available  in  the  MK48  Mod4  Telcom 

Message  identified  as  "Enabled"  using  a  32-bit  flag. 

The  Value  wouuld  be  represent  either  True  or  False. 

The  Weapon  state:Weapon  Under  Control  is 

transmitted  via  UNICAST  to  a  determined  IP  address. 

This  data  would  be  available  in  the  MK48  Mod4 

Weapon  Readback  Message.  This  message  would 

provide  all  of  the  torpedo  parameter  information.  This 

Doppler  Enable,  Ping  Interval,  Target  Mode,  ASH, 

Trajectory  Mode,  Run  Speed,  Run  to  Enable,  Search 

Depth,  Ceiling  and  Acoustid  Mode. 

The  Weapon  state:Bow  Caps  is  transmitted  via 

UNICAST  to  a  determined  IP  address.  This  data 

would  be  available  in  the  Tube  Status  Message 

identified  as  "Bowcap  State"  using  a  16-bit  unsiged 

integer.  The  Value  wouuld  be  represent  either  Open 

or  Shut. 

The  Weapon  state:Bow  Shutters  is  transmitted  via 

UNICAST  to  a  determined  IP  address.  This  data 

would  be  available  in  the  Tube  Status  Message 

identified  as  "Shutter  State"  using  a  16-bit  unsiged 

integer.  The  Value  wouuld  be  represent  either  Open 

or  Shut. 
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The  Weapon  state:Torpedo  Limits  Display  is 

transmitted  via  UNICAST  to  a  determined  IP  address. 

This  data  would  be  available  in  the  MK48  Mod4 

Weapon  Readback  Message.  This  message  would 

provide  all  of  the  torpedo  parameter  information.  This 

message  will  give  all  details  such  as  Search  Speed, 

Doppler  Enable,  Ping  Interval,  Target  Mode,  ASH, 

Trajectory  Mode,  Run  Speed,  Run  to  Enable,  Search 

Depth,  Ceiling  and  Acoustid  Mode. 

The  Uncertainty  of  course  of  COI  is  transmitted  via 

UNICAST  to  a  determined  IP  address..  This  data 

would  be  available  in  the  Threat  Message  identified  as 

"Course  Error”  using  a  32-bit  floating  point  number. 

1  2  •= 

5 

z 

| 

| 

| 

$ 

z 

s 

z 

$ 

z 

$ 

z 

$ 

| 

$ 

z 

Constraints 

z 

z 

z 

z 

1 

Security 

Designation 

UNCLASS  1 

< 

< 

1 

3 

1 

% 

3 

1 

UNCLASS  1 

UNCLASS 

UNCLASS  1 

1 

7 

I 

1 

1 

I 

$ 

z 

1 

1 

$ 

z 

z 

z 

5 

z 

< 

z 

| 

z 

z 

z 

| 

§ 

E 

I 

1 

1 

1 

S 

X 

Tube  Number 

< 

$ 

z 

z 

z 

5 

g 

z 

Multiple: 

Meters,  Yards, 

| 

1 

E 

Update  Rate  of  Info 
Sent  From  System 

| 

i 

When  New  Data 
Received 

When  New  Data 
Received 

When  New  Data 
Received 

1 

I 

< 

0.25  Seconds 

0.25  Seconds 

ra 

la 

11 

Received 

1 

I 

I 

I 

< 

1 

I 

0.25  Seconds 

2 

: 

I 

Time  Between 
Data  Refresh 
Within  System 

i 

I 

Data  Received 

Data  Received 

Data  Received 

! 

I 

< 

0.25  Seconds 

0.25  Seconds 

Data  Received 

Data  Received 

1 

I 

1 

I 

< 

1 

1 

0.25  Seconds 

- 

a 

Q 

5 

2 

1 

1 

E 

2 

8 

1 

2 

§. 

1 

I 

s 

Set  Weapon  State  Messac 

-Tube  Inventory  Message 

2 

E 

1 

2 

1 

2 

1 

a 

2 

2 

-Tube  Status  Message 

-Tube  Status  Message 

1 

1 

2 

2 

■  Threat  Message 

s 

i 

< 

< 

1 

< 

te 

(O 

< 

5 

1 

1 

1 

1 

< 

i 

- 

\ 

l 

s 

X 

8  l 

O  2 

1 

2 

2 

2 

8 

O  2 

fl 

£ 

z 

z 

| 

| 

$ 

i 

$ 

z 

z 

s 

z 

< 

z 

$ 

g 

z 

< 

z 

a 

< 

z 

if* 

a!  =  ° 

i 

i 

1 

2 

i 

i 

2 

1 

2 

2 

2 

s 

2 

5 

2 

1 

|t 

1  Manual  DatE 

1  Collection 

8 

§ 

8 

Manual  DatE 
Collection 

8 

8 

8 

8 

- 

1  Manual  DatE 

1  Collection 

Manual  DatE 
Collection 

1 

E 

3 

8 

Comment 

Description  implies  inventory  count  of 
resources  (MK  48,  SSE,  smoke  candles, 
etc.)  will  be  obtained  from  SFCS,  but  this 
information  is  not  held  bv  SFCS. 

This  information  type  is  missing  from  Design 

IID  Design  Doc  Indicated  as  derived  from 
SFCS?  No  current  capability  to  get  this  info 
from  SFCS. 
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List  of  symbols/abbreviations/acronyms/initialisms 


A-D 

Analog  to  Digital 

AIS 

Automatic  Identification  System 

BSS 

Bathymetric  Sampling  System 

C&PO 

Chief  and  Petty  Officer 

CCS 

Command  and  Control  System 

CFB 

Canadian  Forces  Base 

CO 

Carbon  Monoxide 

CO 

Commanding  Officer 

C02 

Carbon  Dioxide 

COI 

Contact  of  Interest 

CS 

Combat  System 

CSS 

Central  Surveillance  System 

CWA 

Cognitive  Work  Analysis 

DGS 

Data  Gathering  System 

DND 

Department  of  National  Defence 

DRDC 

Defence  Research  &  Development  Canada 

EC 

Engineering  Change 

ECPINS 

Electronic  Chart  Precision  Integrated  Navigation  System 

ESM 

Electronic  Support  Measures 

ETA 

Estimated  Time  of  Arrival 

FY 

Fiscal  Year 

GFI 

Government  Furnished  Information 

GPS 

Global  Positioning  System 

IID 

Information  Integration  Display 

INS 

Inertial  Navigation  System 

IP 

Internet  Protocol 

LAN 

Local  Area  Network 

LMC 

Lockheed  Martin  Canada 

N/A 

Not  Applicable 
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Nav  0 

Navigation  Officer 

02 

Oxygen 

OpO 

Operations  Officer 

OSN 

Ownship  Noise 

R&D 

Research  &  Development 

SDM 

SHINNADS  Dual  Monitor 

SHINNADS 

Shipboard  Integration  Navigation  and  Display  System 

SV 

Sound  Velocity 

TWS 

Tactical  Weapon  System  [Trainer] 

Unk 

Unknown 

VCS 

Victoria  Class  Submarine 

w.r.t. 

With  Respect  To 
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